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SYSTEMS AND METHODS FOR SHARED ELECTRONIC 
5 PURCHASING 

BACKGROUND OF THE INVENTION 
The invention relates generally to the field of 
sales, and in particular to sales at the retail level. More 

10 specifically, the invention relates to systems and methods for 
facilitating the purchase of retail items that are purchased 
from contributions made from one or more individuals using one 
or more forms of payment . 

Retail sales are an important part of the economy. 

15 For example, the value of total retail sales in 1998 is 

expected to exceed $100 billion. Gift giving accounts for a 
large percentage of retail sales, particularly of new and 
high-end goods. One emerging way to purchase retail goods is 
using the Internet. Indeed, Newsweek magazine recently 

20 reported that an estimated $2.3 billion will be spent by 

Americans on Web gifts during 1998. This amount is double 
that spent during 1997. 

One popular way to give a gift is to solicit 
contributions from several people so that resources can be 

25 pooled to purchase a more expensive gift. Typically this is 
done by all the contributors giving money to one designated 
buyer who purchases the item and delivers it to the recipient. 
This practice is common within families where the majority of 
gift giving typically occurs. For example, if a sibling is to 

30 be married, the other siblings may wish to join together to 
purchase a wedding gift, such as a television. Usually, one 
of the siblings then has the responsibility of contacting the 
other siblings, requesting a donation amount, following 
through to make sure that sufficient contributions are 

35 received, and then purchasing the television, preferably all 
before the wedding day. As this example illustrates, gift 
giving by seeking contributions can be fraught with problems. 
For example, contacting each of the proposed contributors can 



WO 00/54122 PCT/USOO/03526 

2 

be difficult, especially if the contributors are separated by 
long distances. To contact each of the contributors, a long 
distance telephone call or a letter may need to be written. 
This can be both time consuming and expensive. Further, 
5 collecting money from each of the proposed contributors can 
also be difficult. For example, the designated buyer will 
typically be unable to use the credit cards of the proposed 
contributors because the designated buyer is typically not 
included on the account. Hence, receiving payment 

10 authorization for the credit cards will be difficult if not 
impossible. Use of cash is typically discouraged because of 
the lack of security in transferring the cash through the mail 
system. Still further, once all of the contributions have 
been collected, the primary buyer then has the responsibility 

15 of selecting the desired item, purchasing the item and then 
providing it in suitable form to the recipient. 

In summary, existing processes for gift giving when 
multiple contributions are sought are inefficient. More 
specifically, existing processes are both time consuming and 

20 have high transaction costs. Further, existing processes are 
inconvenient, particularly for the designated buyer who has 
the responsibility of coordinating gift selection, 
contribution amount, contribution collections and delivery. 

Hence, it would be desirable to provide systems and 

25 methods to facilitate the purchase of items when soliciting 

contributions from one or more contributors using one or more 
forms of payment. The systems and methods should be both 
efficient and easy to use. Preferably, the systems and 
methods will utilize computers which are coupled to a network, 

30 such as the Internet, to reduce the transaction costs involved 
in the purchasing process . 

SUMMARY OF THE INVENTION 
The invention provides exemplary systems and methods 
35 for facilitating purchase transactions. More specifically, 
the methods and systems of the invention are employed to 
facilitate the sale of items where one or more contributions 
are made toward the purchase price of the item. The systems 
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and methods of the invention are particularly useful when the 
proposed contributions are made using one or more forms of 
payment . 

According to the invention, techniques are provided 
for synchronizing multiple charges (from multiple 
contributors) to multiple payment instruments when purchasing 
an item. According to one exemplary method, multiple proposed 
contributions toward the purchase price of an item using 
multiple payment instruments are collected. Preferably, the 
contributions are collected at a merchant server computer. 
The merchant server computer then sends requests for 
authorizations to charge the payment instruments. Typically, 
these requests will be sent to banks or other credit 
organizations who have authority to charge the payment 
instruments. The merchant server computer then waits for 
returned responses to the authorization requests. If the 
responses indicate an authorization to charge all of the 
payment instruments, the merchant server computer sends out 
commands to charge all of the payment instruments. However, 
if any one of the responses indicates a failed authorization, 
then none of the payment instruments are charged. In this 
way, charging of the payment instruments is synchronized so 
that none of the payment instruments will be charged unless 
the authorized charges are sufficient to cover the purchase 
price of the item. 

The merchant server computer is preferably coupled 
to a network to which various other computers are also 
coupled . In one particular aspect, the item that is desired 
to be purchased is selected from a primary buyer computer 
which is coupled to the network. The selection of the item is 
then sent over the network to the merchant server computer. 
The selection of the item is then sent to. one or more co-payer 
computers over the network along with a request to contribute 
toward the purchase price. Preferably, the primary buyer 
identifies the co-payers who may wish to contribute toward the 
purchase price. Conveniently, the primary buyer may also 
compose a solicitation letter at the primary buyer computer 
which contains a request for a contribution towards the 
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purchase price. This information is then sent over the 
network to the identified co-payer computers . After the co- 
payers have read the solicitation letter, responses to the 
letter are sent over the network to the merchant server 
computer, with the responses preferably indicating a proposed 
contribution towards the purchase price. 

In another part icular aspect , a notification is sent 
over the network to the primary buyer computer when the 
contributions from the co-payers meet or exceed the purchase 
price. The primary buyer is then able to confirm the 
selection from the primary buyer computer. 

In still another aspect, once the primary buyer 
computer has confirmed that the item should be purchased, the 
merchant server computer sends a request to banks or credit 
organizations asking for authorizations to charge the payment 
instruments as previously described. The merchant server 
computer then collects the returned responses and sends 
commands to charge all of the payment instruments only if the 
responses indicate an authorization to charge all of the 
payment instruments. Once all of the payment instruments have 
been charged, the item has been purchased and is sent to an 
indicated recipient. 

The invention further provides an exemplary system 
for facilitating a purchase transaction. The system comprises 
at least one network server computer which may be coupled to a 
network to allow the network server computer to communicate 
with a primary buyer computer and one or more co-payer 
computers. The system includes code to present a list of 
inventory items at the primary buyer computer. In this way, a 
primary buyer may utilize the primary buyer computer to select 
one of the items to purchase at a given purchase price. The 
system further includes code to send a message to the co-payer 
computer requesting whether contributions are to be made 
toward the purchase price of the item using a given payment 
instrument. Code is also included to determine when one or 
more proposed contributions toward the purchase price meets or 
exceeds the purchase price. Still further, the system 
includes code to send a command to charge the payment 
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instruments to pay the purchase price. In this way, once the 
network server computer receives proposed contributions which 
meet or exceed the purchase price, commands are sent to charge 
the payment instruments to pay the purchase price. 

In one particularly preferable aspect, the network 
server computer is also configured to be coupled to at least 
one credit organization which has authority to charge the 
payment instruments. The system preferably also includes code 
to contact the credit organization to authorize the charging 
of the payment instruments. The system preferably also 
includes code to send commands to the credit organizations to 
charge the payment instruments only after receiving 
authorizations from the credit organizations to charge all of 
the payment instruments. In this way, the payment instruments 
will not be charged unless all of the charges are 
preauthor i zed . 

In another particular aspect, the system includes 
code to send over the network a notification to the primary 
buyer computer of any proposed contributions. A notification 
is preferably also sent over the network to the primary buyer 
computer when the proposed contributions meet or exceed the 
purchase price. Still further, this system preferably 
includes code to send a confirmation of the selection from the 
primary buyer computer to the network server computer to allow 
the primary buyer to confirm that the item is still desired to 
be purchased. . Optionally, the primary buyer may also wish to 
contribute towards the purchase price. This may be done by 
sending a proposed contribution from the primary buyer 
computer to the network server computer. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a schematic diagram of an exemplary system 
to facilitate a purchase transaction according to the 
invention. 

Fig. 2 illustrates a flowchart outlining the steps 
of an exemplary method for facilitating a purchase transaction 
using the system of Fig. 1 according to the invention. 
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Fig. 3 illustrates a flowchart outlining an 
exemplary refunding processing according to the invention. 

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

In a broad sense, the invention provides for the 
synchronization of multiple charges to multiple payment 
instruments. In this way, none of the payment instruments will 
be charged until all of the proposed charges are authorized. 
Once all the authorizations are received, the invention 
provides for the charging of each of the payment instruments. 

The techniques of the invention will find their 
greatest use in facilitating the purchase of items where 
contributions are received from multiple individuals using 
multiple forms of payment instruments. Typically, the items 
to be purchased will be those sold at the retail level, 
including clothing, footwear, consumer durable goods, jewelry, 
toys, food, parts, and the like. However, it will be 
appreciated that the invention is not limited to the 
particular type of item that is to be purchased. 

As just described, one important feature of the 
invention is the ability to synchronize multiple charges to 
multiple payment instruments. The types of payment 
instruments that may be used with the invention include credit 
cards, debit cards, negotiable instruments such as checks, 
prepaid accounts, smart cards, utility bills, credit accounts, 
billing services, electronic funds transfer, bank accounts, 
brokerage accounts, and money market funds, and the like. Of 
these, the invention will find its greatest use when the form 
of payment instrument is a credit card. 

The standard practice among credit card companies is 
to utilize a two-step process in handling payments. The first 
step is payment authorization. When a payment is authorized, 
the designated amount of funds is reserved on the card but no 
actual transfer of money occurs. The second step is payment 
settlement. In this step, the card is actually charged and 
the money is transferred to the payee's account. The present 
invention takes advantage of this two-step process to help 
insure that none of the cards are charged until an 
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authorization is received for each of the cards. If any of 
the cards receives a failed authorization, then none of the 
cards are charged. In this way, the synchronization of 
charges to multiple cards is provided. 
5 The techniques of the invention preferably utilize 

modern computer technology. More specifically, the methods of 
the invention are preferably practiced utilizing various 
computers which are able to communicate with each other over a 
network. For example, one configuration of a system 10 that 

10 may be employed to implement the techniques of the invention 
is illustrated in Fig. 1. System 10 preferably employs the 
use of a primary buyer computer 12 and one or more co-payer 
computers 14. Computers 12 and 14 may be of any type of 
computer that will support a Web browser, including any one of 

15 a variety of commercially available personal computers, such 

as those employing a Pentium- type processor. Merely by way of 
example, such computers can include desktop computers, 
workstations, laptop computers, Web TV devices, hand-held 
devices, and the like. As such, the invention is not limited 

20 to the particular type of computer needed to implement the 
methods of the invention. 

Computers 12 and 14 may be constructed to be 
essentially identical to each other and preferably each 
comprises a processor chassis 16 within which is disposed a 

25 central processing unit (CPU) and supporting integrated 

circuitry. Coupled to processor chassis 16 is a keyboard (not 
shown) and a monitor 18. Input into computers 12 and 14 may 
be accomplished by use of the keyboard and/or a mouse (not 
shown) or other pointing device that controls a cursor that is 

30 in turn used to make selections in programs executed on 

computers 12 and 14. Optionally, computers 12 and 14 may also 
include a floppy drive 20, a compact disk drive 22, and an 
internal hard drive as is known in the art. Computers 12 and 
14 preferably also include an internal/external modem as is 

35 known in the art. 

To communicate with other computers, the computers 
of the invention are preferably coupled to a network, such as 
the Internet 24. However, it will be appreciated that other 
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types of networks may be employed to operate the invention, 
including local area networks (LAN) , wide area networks (WAN), 
a corporate intranet /extranet , secured private networks, and 
the like. Indeed, Internet 24 is depicted as an amorphous 
shape to suggest that the details of connection with the 
various computers are continually evolving. 

System 10 further includes a merchant server 
computer 26 which is able to communicate with computers 12 and 
14 via Internet 24 . Merchant server computer 28 is employed 
to transfer various information between computer 12 and 
computers 14 as well as between a credit organization computer 
28. The connection between merchant service computer 26 and 
credit organization computer 28 is preferably provided over a 
secured network such as a value added network (VAN) . 
Alternatively, computers 26 and 28 may be coupled together 
using dial-up link open modems and the telephone network or an 
encrypted connection over the Internet. 

Credit organization computer 28 includes a database 
of various individuals and their credit account status. In 
this way, computer 28 is able to issue authorizations to 
charge various payment instruments. Further, computer 28 is 
able to initiate commands to transfer money from an account to 
complete a purchase as is known in the art. Although shown 
with only one credit organization computer 28, it will be 
appreciated that merchant server computer 28 may be connected 
to multiple credit organization computers depending on which 
credit organizations need to be contacted in order to charge a 
payment instrument. Credit organization computers 28 are 
typically operated by a bank which has associations with 
various credit card companies, such as VISA and MasterCard. 
Alternatively, credit organization computer 28 may be operated 
directly by a credit card company, such as American Express. 

Merchant server computer 26 is preferably an Intel 
Pentium or Digital alpha-based microprocessor computer, 
running Microsoft Windows NT. All of the specialized software 
required to manage the methods of the invention run on 
merchant server computer 26 as described hereinafter. 
Software tools that may be employed to implement the methods 
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of the invention on merchant server computer 28 include 
Microsoft SiteServer Commerce Edition as the base platform. 
Various custom components may be built using Microsoft Active 
Server Pages and Microsoft Visual C++. Links to the various 
credit payment computers 28 may be supported by software from 
Veriphone or CyberCash. Further, credit organization 
computers 28 typically comprise mainframe computers as is 
known in the art . 

The specific hardware and software described in 
connection with system 10 is merely illustrative of hardware 
and software that may be employed to implement the methods of 
the invention. Hence, it will be appreciated that the 
invention is not limited to the specific types of hardware and 
software employed to implement the invention. 

Referring now to Fig. 2, one exemplary method for 
facilitating a purchase transaction where one or more 
contributions are made using one or more payment instruments 
will be described. For convenience of discussion, reference 
will be made to a primary buyer, co-payers, and a recipient. 
The primary buyer is the individual who initiates the 
purchase, solicits other contributors, and provides final 
purchase authorization. The co-payers are additional people 
who contribute toward the purchase price. The recipient is 
the person who receives the item or items being purchased. It 
will be appreciated that the recipient may also be the primary 
buyer or a co-payer. For example, a child may purchase an 
item for himself and solicit contributions, or the full 
amounts, from a parent. Accordingly, the primary buyer does 
not necessarily have to contribute anything to the purchase. 

In the method of Fig. 2, three subprocesses are 
employed. These include steps 30-46, 48-68, and 70-92. In 
describing the method of Fig. 2, reference will also be made 
to Fig. 1. The first subprocess is the initial order 
subprocess. As illustrated in step 30, the process begins 
when the primary buyer chooses an item to purchase. As shown 
in step 32, the primary buyer browses and/or searches an 
online catalog and selects the item to purchase. The online 
catalog preferably resides on merchant server computer 26 and 
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is viewed on monitor 18 of primary buyer computer 12 as shown 
in Fig. 1. In this way, the primary buyer is able to utilize 
primary buyer computer 12 to select the desired item from an 
online catalog. Once the item has been selected, it is added 
to the primary buyer's order and stored in merchant server 
computer 26. 

As shown in step 34, the primary buyer is given the 
option of choosing more items that are to be added to the 
order. If so, the primary buyer simply returns to step 32 and 
selects another item. Once all the items to be purchased have 
been selected, the method proceeds to step 36 where the 
primary buyer selects one or more .co-payers that the primary 
buyer wishes to contribute to the purchase price of the item 
or items. The selection of the co-payers may be accomplished 
by typing into primary buyer computer 12 the name of a co- 
payer and an e-mail address, or other identifier that will be 
recognized by merchant server computer 26. As shown in step 
38, the primary buyer is given the option of selecting other 
co-payers who may wish to contribute toward the purchase 
price. 

Once all the co-payers are selected, the method 
proceeds to step 4 0 where the primary buyer is given the 
option of entering his or her own personal contribution toward 
the purchase price. The primary buyer may choose not to 
contribute by simply entering a zero amount. If the primary 
buyer does wish to contribute, the primary buyer enters his or 
her credit card information into primary buyer computer 12 
where it is transferred to merchant server computer 26. The 
primary buyer is further given the option of composing a 
solicitation letter to the co-payers explaining who is to 
receive the item and why they are being asked to contribute as 
illustrated in step 42. As shown in step 44, merchant server 
computer 26 forwards the solicitation letter along with the 
order itemization to the co-payer computers which correspond 
to the co-payers identified by the primary buyer. For 
example, the primary buyer may enter the e-mail address for 
each of the proposed contributors. This information is 
processed by merchant server computer 26 who then sends the 
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solicitation letter and order itemization to the appropriate 
co-payer computers. Once this is accomplished, the initial 
order subprocess is complete as illustrated in step 46. 

Steps 48-60 illustrate a co-payer contribution 
subprocess. This subprocess starts when one of the co-payers 
reads the solicitation letter as shown in step 50. The 
solicitation letter preferably includes a hypertext link 
and/or instructions on how to contribute a payment toward the 
purchase price of the item. The co-payer simply selects its 
link or follows the instructions that are provided. As shown 
in step 52, the Co-payer is asked whether they wish to 
contribute toward the purchase price of the item. If the co- 
payer wishes to contribute, the process proceeds to step 56. 
Otherwise, the process proceeds to step 54. If no 
15 contribution is to be supplied, the co-payer simply enters a 
zero amount into co-payer computer 14. If the co-payer does 
wish to contribute, the amount of the contribution and the 
credit card information are entered into co-payer computer 14. 
The co-payer is also given the option to enter comments 
20 regarding the contribution, as shown in step 58. If so, the 
co-payer enters the comment into co-payer computer 14 as 
illustrated in step 60. Information entered into co-payer 
computer 14 is transferred to merchant server computer 26 
where it is stored. Further, merchant server computer 26 e- 
25 mails a notice of the contribution (or lack thereof) and the 
comments (if any) to primary buyer computer 12 and all other 
co-payer computers 14 as shown in step 62. 

Merchant server computer 26 totals all of the 
existing contributions and determines whether the sum is more 
than the order total, preferably including tax, shipping and 
handling, as shown in step 64. If so, the method proceeds to 
step 66. Otherwise, the method proceeds to step 68. If the 
contributions are sufficient, a notice is sent to primary 
buyer computer 12 indicating that the total contribution is 
35 adequate. The co-payer contribution process is then complete. 

Steps 70-92 illustrate the order of confirmation 
subprocess. In this subprocess, the buyer reads the notice 
that sufficient contributions have been authorized, as shown 
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in step 72. Optionally, primary buyer computer 12 may be sent 
information about who is contributing. At this point, the 
primary buyer has the option as to whether to proceed with the 
existing contributions or wait for additional contributions 
5 (which may reduce the actual amounts that the existing 

contributors pay) as shown in step 74. As shown in step 76, 
if the primary buyer declines to accept the order, the primary 
buyer may simply wait for additional contributions. 
Preferably, a notice will be sent to primary buyer computer 12 

10 each time additional contributions are proposed. In this way, 
the primary buyer may return at any time to confirm the order. 

Once the primary buyer confirms the order, merchant 
server computer 26 sends an authorization request to each 
relevant credit management computer 28 to see if the banks or 

15 credit organizations will authorize the charges as shown in 
step 78. Merchant . server computer 26 receives the responses 
from credit management computers 28 and analyzes the responses 
to determine if any of the authorizations have failed as shown 
in step 80. If one or more of the authorizations have failed, 

20 all successful authorizations are preferably cancelled and the 
contributions that failed are reset as shown in step 82. A 
notification is also sent to the primary buyer computer 12 as 
shown in step 84. The failed co-payer is preferably also 
notified by sending a message from merchant server computer 26 

25 to co-payer computer 14. At this point, the process proceeds 
to step 86 where the process will restart once the primary 
buyer receives notice that sufficient contributions again 
exist . 

As shown in step 88, if all authorizations are 
30 successful, all of the cards are charged. Once the payment 

for the item has been accepted, the order is filled, as shown 
in step 90. The order confirmation sub-process is then 
complete as shown in step 92. Preferably, once the item has 
been purchased, it will be delivered via mail or other 
35 delivery system to the recipient. 

It will appreciated that the method of Fig. 2 is one 
exemplary method of purchasing an item. However, various 
alternatives to this method may be used to facilitate 
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transaction processes. For example, instead of waiting until 
sufficient contributions have been proposed before authorizing 
the credit cards, the credit card of a co-payer may be 
authorized immediately after the contribution information is 
entered into the co-payer computer. This is advantageous in 
that, if a mistake was made while entering the number, such a 
mistake may be detected and immediately corrected. Further, 
only the co-payer, i.e., the card holder, will know when the 
card has failed authorization. In this way, the primary buyer 
and the other co-payers will not be aware of any credit 
problems of the other co-payer. 

Authorizations for. credit cards typically only hold 
for about 4-7 days. However, the authorizations can be 
refreshed by merchant server computer 26 to prevent 
expiration. More specifically, if it takes longer than the 
amount of time for the other co-payers to make their 
contribution, merchant server computer 2 8 will send a request 
to refresh the authorizations. Because a co-payer will 
typically not wish to have funds perpetually reserved on their 
credit card, merchant server computer 28 is preferably 
configured with an expiration date at which point it will 
cease sending requests to refresh the authorization. 

In one aspect, the ordered item or items may be 
immediately reserved in inventory when the initial order is 
placed at primary buyer computer 12. Typically, the warehouse 
having the items has access to the database in merchant server 
computer 26 so that it will know when an order has been 
placed. Hence, once a notification has been received of an 
order, the warehouse may immediately reserve the item. In 
this way, there is no need to wait for all co-payers to send 
in their proposed contributions before securing the order. 
Merchant server computer 26 is preferably configured so that 
the reservation will be released after a predetermined amount 
of time has passed so that the item will not remain 
perpetually reserved. In the event that the item is not in 
stock, the warehouse may immediately backorder to replenish 
the inventory without waiting for the process to complete. 
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In some cases, the sum of the proposed contributions 
may exceed the total cost of the item or items. In such a 
case, merchant server computer 26 may be configured to 
proportionally charge each co-payer the amount the co-payer 
contributed relative to the sum of all the contributions. 
Typically, credit card companies are able to accept 
settlements that are less than the authorized amount. 

In one alternative, the primary buyer is given the 
option at primary buyer computer 12 to include proposed 
contribution amounts for each of the selected co-payers. The 
primary buyer may select to have the proposed contribution 
amounts generally known to each co-payer or to be private to 
the individual co-payer. 

Another feature of the invention is the ability to 
15 accommodate refunds or returns by reversing the charges on the 
payment instruments used in the original purchase. One 
exemplary method for accommodating refunds is illustrated in 
Fig. 3. At step 100 the refunding process begins. This may 
be a request for a refund and/or the recipient may return the 
20 purchased goods as shown in step 102. The request is 
evaluated as shown, in step 104. If the request is not 
approved, the process ends at step 106. If approved, the 
process proceeds to step 108 where the multi-instrument 
payment is split into a set of independent refunds (since 
25 multiple payment instruments were used in the original 

transaction) . . in this way, each payment instrument that was 
used in the original transaction may have its charges 
reversed. This is shown in step 110. If any of the reversals 
are unsuccessful, the processes is repeated for the 
30 unsuccessful attempts. In some cases, it may be impracticable 
or impossible to issue a reversal, e.g. the payor has closed 
his or her credit-card account. In such a case, a refund 
check may be issued and mailed to the payor. After all 
reversals have been accomplished, the process ends at step 
35 112. 

The process of Fig. 3 takes advantage of the 
unlikelihood that the reversals will fail due to a lack of 
credit on the part of the vendor. As such, it is not 
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necessary to synchronize the refunds as is the case with the 
original purchase. Instead, it is only necessary to ensure 
that all refunds eventually occur. 

In another option, the contribution amounts may be 
5 kept confidential, so that only the contributors know how much 
was authorized. Further, the names of the contributors and/or 
the primary buyer might be kept confidential. 

In the case of charitable situations, system 10 may 
be configured to offer an option for an open solicitation for 
10 contributions with the names and amounts of the contributions 
being kept confidential. In this manner, anyone may choose to 
contribute without being named by the primary buyer. 

In another alternative, the item to be purchased may 
be a gift certificate or cash. The gift of cash is 
15 particularly useful when utilizing the confidential 

contribution option as described above. In this way, a system 
is provided to easily and conveniently collect contributions 
for a charitable cause. 

When the item to be purchased is a gift 
20 certificate or cash, the purchase may be settled on a 
particular date regardless of the total amount of the 
contributions. The gift certificate or cash amount would 
simply be the total of contributions on the ending date. 
Alternatively, the transaction may be kept open with regular, 
25 periodic statements as a way to continuously collect funds for 
a particular purpose * 

When the item being purchased is cash, the cash 
amount may be less than the total of all the contributions. 
This may happen, for example, when a credit card company 
charges a small percentage of the transaction. 

In another alternative, the total amount required or 
contributed may be hidden from both the co-payers and the 
primary buyer. This may be particularly useful when there is 
a confidential set of co-payers. 
3 ^ In still another alternative, the primary buyer may 

shop for items from primary buyer computer 12 before 
identifying that any co-payers will be used. In this manner, 
the primary buyer is able to assemble an order and then select 



30 



WO 00/54122 PCT/US00/03526 

16 

the option of asking co-payers to contribute at the time of 
payment. Preferably, each time an item is selected it is 
added to a shopping cart as in known in the art. See, for 
example, U.S. Patent No. 5,715, 314, the complete disclosure 
of which is herein incorporated by reference, and web sites, 
isuch as www . gap . com and www . nords t rom . com . 

The hosting organization of merchant server computer 
26, e.g., the organization responsible for providing and 
shipping the items, may offer members a credit account with an 
established billing/payment system. In this way, the primary 
buyer or co-payer who is a member of the organization hosting 
the site need not enter any payment instrument information. 
Rather, the members may be directly billed and the process may 
proceed with only the entry of the contribution amount. 

In another option, merchant server computer 2 6 may 
store the credit card information in its database so that, on 
subsequent visits, the user may simply choose to use the card 
instead of re-entering the credit card information. 

As previously described, the methods may be employed 
to order one or more items. In the case where only a single 
item is to be purchased, merchant server computer 26 may be 
configured to display an "instant purchase" button on monitor 
18 of primary buyer computer 12. In this manner, the shopping 
cart process is bypassed and allows the primary buyer to 
immediately begin selecting the co-payers. 

As previously described, a variety of payment 
instruments may be employed with the methods of the invention. 
Hence, the invention is not limited to the use of credit card 
payments. Indeed, other payment mechanisms may be used where 
it is possible to separate the authorization step from the 
settlement step. As one example, a check may be used for 
payment. In such a case, merchant server computer 28 is able 
to communicate with a bank to determine if sufficient funds 
are in the payor's account before processing the check. 
However, due to the nature of checks, the check may only be 
used for the stated amount and not a reduced amount as with a 
credit card. In the event that the co-payers contribute in 
excess of the purchase price, refund checks may be issued to 
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the co-payers. Alternatively, a gift certificate for the 
excess amount may be enclosed with the purchased item. 

The invention may also be utilized to allow 
contributors to purchase gift certificates. In such a method, 
each of the co-payers purchases a gift certificate using their 
co-payer computer. This information is then transferred to 
the primary buyer via primary buyer computer 12. Such gift 
certificates are "virtual" certificates that take the form of 
credit in the primary buyer's account as saved on merchant 
server computer 26 rather than physical certificates. Once 
the primary buyer has received sufficient certificates 
(credit) , the primary buyer proceeds to make the purchase 
using the certificates for payment. 

Another alternative method is a purchase 
authorization method. According to this method, the co -payers 
authorize the primary buyer to use their payment instrument to 
purchase a particular item (or set of items) up to a certain 
maximum contribution. Once the primary buyer receives 
sufficient contributions, the primary buyer proceeds with the 
purchase . 

In still another option, contributions may be 
collected for items other than those listed by the merchant 
server computer. With this option, the contributions are 
collected and saved in a "purchasing account" which may be 
drawn on by the buyer. In this way, essentially any type of 
item may be purchased, regardless of whether it is offered by 
the vendor operating the merchant server computer. 

For example, the primary buyer simply need to 
transmit to the merchant server computer the name of an item 
that is to be purchased along with an appropriate description 
and cost. Requests for contributions are solicited in a 
manner similar to that previously described. Once sufficient 
funds have been collected as previously described, the funds 
are stored in a "purchasing account". The primary buyer has 
access to the funds in this account and can withdraw the funds 
to purchase the item. For example, a credit card, debit card, 
negotiable instrument, or other transaction instrument my be 
issued to the primary buyer who may use the transaction 
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instrument to apply the funds in the purchasing account 
towards the transaction. 

The invention has now been described in detail for 
purposes of clarity of understanding. However, it will be 
5 appreciated that certain changes and modifications may be 
made. Therefore, the scope and content of the invention 
should be determined in light of the claims set forth below as 
well to the full range of equivalents to which those claims 
are entitled. 
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1 . 1. A method for facilitating a purchase 

2 transaction, comprising: 

3 selecting from a primary buyer computer an item that 

4 is desired to be purchased by payment of a purchase price; 

5 collecting at least one proposed contribution toward 

6 the purchase price from at least one co-payer computer; and 

7 accepting an amount of the proposed contribution 

8 sufficient to meet the purchase price. 

1 2. A method as in claim 1, further comprising 

2 entering a contribution toward the purchase price from the 

3 primary buyer computer. 

1 3. A method as in claim 1, further comprising 

2 identifying at : the primary buyer computer at least one co- 

3 payer from which proposed contributions are to be collected. 

1 4. A method as in claim 3, further comprising 

2 composing a solicitation letter at the primary buyer computer 

3 which contains a request for a contribution toward the 

4 purchase price and sending the letter to the co-payer 

5 computer. 

1 5. A method as in claim 1, further comprising 

2 selecting the item from an inventory of items displayed at the 

3 primary buyer computer. 

1 6. A method as in claim 1, further comprising 

2 sending a notification to the primary buyer computer of any 

3 proposed contributions. 



1 

2 
3 



7. A method as in claim 1, further comprising 
sending a notification to the primary buyer computer when the 
contribution meets or exceeds the purchase price. 
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1 8. A method as in claim 7, further comprising 

2 confirming the selection from the primary buyer computer after 

3 receiving the notification. 

1 9. A method as in claim 8, wherein the proposed 

2 contribution is in the form of a credit purchase using a 

3 payment instrument, and further comprising authorizing 

4 charging of the payment instrument prior to accepting the 

5 amount . 

1 10. A method as in claim 9, further comprising 

2 collecting multiple proposed contributions using multiple 

3 payment instruments, and wherein the amount is accepted by 

4 charging the payment instruments only after authorizations to 

5 charge all of the payment instruments have been received. 

1 11. A method as in claim 1, further comprising 

2 delivering the ordered item to a recipient. 

1 12. A method for facilitating a purchase 

2 transaction, comprising: 

3 selecting from a primary buyer computer which is 

4 coupled to a network an item that is desired to be purchased 

5 by payment of a purchase price; 

6 sending the selection of the item to one or more co- 

7 payer computers over the network along with a request to 

8 contribute toward the purchase price; 

9 collecting proposed contributions toward the 

10 purchase price from the co-payer computers; and 

11 accepting an amount of the proposed contributions 

12 sufficient to meet the purchase price. 



1 

2 
3 



13. A method as in claim 12, further comprising 
collecting a contribution toward the purchase price from the 
primary buyer computer. 
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14. A method as in claim 12 , further comprising 
identifying at the primary buyer computer co-payers who may 
wish to contribute to the purchase price. 

15. A method as in claim 14, further comprising 
composing a solicitation letter at the primary buyer computer 
which contains a request for a contribution toward the 
purchase price and sending the letter over the network to the 
co-payer computers. 

16. A method as in claim 12, further comprising 
sending over the network a notification to the primary buyer 
computer of any proposed contributions. 

17. A method as in claim 12, further comprising 
sending over the network a notification to the primary buyer 
computer when the contributions meet or exceed the purchase 
price. 

18. A method as in claim 17, further comprising 
confirming the selection from the primary buyer computer after 
receiving the notification. 

19. A method as in claim 18, wherein the proposed 
contributions are in the form of a credit purchase using 
multiple different payment instruments, and further comprising 
sending authorization requests to banks or credit 
organizations who have authority to charge the payment 
instruments prior to accepting the amount. 

20. A method as in claim 19, wherein the amount is 
accepted by charging the payment instruments only after 
authorizations to charge all of the payment instruments have 
been received. 

21. A method as in claim 12, further comprising 
delivering the item to a recipient. 
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22. A system for facilitating a purchase 
transaction, comprising : 

at least one network server computer which is 
adapted to be coupled to a network to allow the network server 
computer to communicate with a primary buyer computer and at 
least one co-payer computer; 

code to present a list of inventory items at the 
primary buyer computer to allow the primary buyer computer to 
select one of the items to purchase at a given purchase price; 

code to send a message to the co-payer computer 
requesting whether a contribution is to be made toward the 
purchase price of the item using a payment instrument; 

code to determine when one or more proposed 
contributions toward the purchase price meets or exceeds the 
purchase price; and 

code to send a command to charge the payment 
instrument (s) to pay the purchase price. 

23. A system as in claim 22, further comprising 
code to send over the network a notification to the primary 
buyer computer of any proposed contributions. 

24. A system as in claim 22, further comprising 
code to send over the network a notification to the primary 
buyer computer when the proposed contributions meet or exceed 
the purchase price. 

25. A system as in claim 24, further comprising 
code to send a confirmation of the selection from the primary 
buyer computer to the network server computer after receiving 
the notification to confirm that the item is to be purchased. 

26. A system as in claim 25, wherein the network 
server computer is also adapted to be coupled to at least one 
credit organization, wherein at least one of the proposed 
contributions involves a credit transaction, and further 
comprising code to contact the credit organization to 
authorize the charging of the payment instrument (s) . 
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27. A system as in claim 26, wherein the network 
server computer receives proposed contributions from multiple 
different payment instruments, and further comprising code to 
send the command to charge the payment instruments only after 
receiving authorization from the credit organization to charge 
all of the payment instruments. 

28. A method for facilitating a purchase 
transaction, comprising : 

at a merchant server computer, collecting multiple 
proposed contributions toward a purchase price of an item 
using multiple payment instruments ; 

sending from the merchant server computer requests 
for authorization to charge the payment instruments; 

at the merchant server computer, collecting returned 
responses to the authorization requests; 

sending from the merchant server computer commands 
to charge all of the payment instruments only if the responses 
indicate an authorization to charge all of the payment 
instruments . 

29. A method as in claim 28, wherein the payment 
instruments are selected from the group consisting of credit 
cards from different credit organizations, debit cards, smart 
cards, utility bills, credit accounts, billing services, 
electronic funds transfer, bank accounts, brokerage accounts, 
and money market funds. 

30. A method as in claim 28, further comprising 
sending the proposed contributions to the merchant server 
computer from multiple co-payer computers which are coupled to 
the merchant server computer over a network. 

31. A method as in claim 30, further comprising 
sending a list of proposed contributors to the merchant server 
computer from a primary buyer computer which is coupled to the 
network, and sending requests for proposed contributions to 
the co-payer computers over the network. 
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1 32. A method as in claim 28, further comprising 

2 sending the authorization requests to banks or credit 

3 organizations who have authority to charge the payment 

4 instruments . 

1 33. A method for facilitating a purchase 

2 transaction over a network of computers, the method 

3 comprising: 

4 receiving a selection of an item that is desired to 

5 be purchased by payment of a purchase price from a primary 

6 buyer computer; 

7 collecting at least one proposed contribution toward 

8 the purchase price from at least one co-payer computer; and 

9 accepting an amount of the proposed contribution 
10 sufficient to meet the purchase price. 

1 34. A method as in claim 33, further comprising 

2 collecting multiple contributions from multiple co-payer 

3 computers, wherein the proposed contributions are in the form 

4 of a credit purchase using multiple different payment 

5 instruments, and further comprising sending authorization 

6 requests to banks or credit organizations who have authority 

7 to charge the payment instruments prior to accepting the 

8 amount . 

1 35. . A computer readable medium containing a program 

2 for transacting a sale over a network of computers comprising 

3 the steps of : 

4 receiving a selection of an item that is desired to 

5 be purchased by payment of a purchase price from a primary 

6 buyer computer; 

7 collecting at least one proposed contribution toward 

8 the purchase price from at least one co-payer computer; and 

9 accepting an amount of the proposed contribution 
10 sufficient to meet the purchase price. 
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system he or she is invited to register and complete the transaction. 
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SYSTEM AND METHOD FOR ELECTRONICALLY 
EXCHANGING VALUE AMONG DISTRIBUTED 

USERS 

5 BACKGROUND 

This invention relates to the fields of computer systems and communications. More 
particularly, a system and methods are provided for facilitating the exchange of value 
among distributed users through computing devices. 

Existing methods of transferring or exchanging values among multiple persons have 

10 many shortcomings. For example, the use of cash requires regular replenishment, creates 
the need to make change, allows the possibility of theft or loss and has no built-in or easy 
method of keeping records concerning cash payments and receipts. Similarly, checks can 
be forged, they often provide only rudimentary record keeping (e.g., check stubs) and allow 
one to unwittingly overdraw a checking account. Credit cards may mitigate some of the 

1 5 problems with cash and checks, but cannot be used for making payments or exchanging 
value between two or more individuals. 

In addition, the formalities of existing value exchange transactions can make them 
inefficient or difficult to complete. For example, transferring money to another person's 
bank or other financial account may require one to know the person's account number. 

20 That person may understandably be reluctant to divulge such information. 

Thus, what is needed is a system and method for enabling value transfers without all 
the shortcomings of existing means and techniques. It would be desirable, for example, to 
allow a value exchange transaction to be conducted using a known or common identifier of 
a person (e.g., electronic mail address, telephone number) rather than other, more sensitive, 

25 information. 

SUMMARY 

In one embodiment of the invention a system and methods are provided for 
conducting a value exchange between two or more persons using a distributed value 
30 exchange system. 
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In this embodiment the system may comprise one or more system servers 
configured to register a person or other entity (e.g., a business) as a system user and allow 
him or her to conduct value exchange transactions with persons who may or may not also 
be registered users. A user then employs a client computing device (e.g., a handheld, 
5 palmtop or desktop computer, a web-enabled telephone, a two-way pager) to initiate or 
conduct a value transfer. The value exchange may be conducted while online with (e.g., 
connected to) the system, while offline, while connected (e.g., via wireless connection) to 
another user's device, etc. When the transaction is submitted to the system, it notifies 
transaction parties that are as-yet unaware of the transaction and attempts to clear or 
1 0 finalize the transaction and adjust the users' account balances appropriately. 

A communication server may be configured to receive connections (e.g., wired 
and/or wireless) from persons wishing to become registered users. A synchronization 
server may be configured to facilitate the synchronization of user's client devices with the 
system. During synchronization, users* devices may submit transactions to the system, 
1 5 receive information on new or cleared transactions, synchronize account information on the 
system with the information on the client device, etc. A security server may be configured 
to enforce security procedures, possibly using asymmetric and/or symmetric cryptographic 
techniques. A financial server interacts with other system servers and external financial 
institutions to enable a user to inject value into the system and withdraw value from the 
20 system. One or more databases may store account information for users (e.g., account 
information, transaction details) and help coordinate system activity. 

In one method of conducting a value exchange a person registers with the system, 
an account is created for him and system software is downloaded to his client device. The 
user may then conduct transactions on his client whether he is connected to the system or 
25 not When not connected, the client stores transaction details and, when later connected to 
the system for synchronization purposes, uploads his transactions to the system and may 
receive transactions initiated by other users. Each transaction may include an identifier of 
another party to the transaction and the value to be exchanged. In one embodiment of the 
invention transaction parties may be identified by identifiers that have meaning outside the 
30 system, such as electronic mail addresses, telephone number, social security numbers, etc. 
Thus, the user may initiate a transaction with a person who is not a registered user as long 
as he knows an appropriate identifier of the person. 
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When the system receives a new transaction initiated by a user it attempts to contact 
the other party or parties using the identifiers) provided by the initiating user. If another 
party is a registered user, the system may also know other methods of contacting the party. 
For a party who is not already a user, he or she is invited to connect to the system, register 

5 and complete the transaction. 

Virtually any means of value transfer may be associated with the system. Users 
may introduce value into their system accounts via credit card, check, cash, electronic funds 
transfer, direct deposit, etc. Value may be withdrawn from the system using the same or 
similar processes. The value that is exchanged between transaction parties may be 

1 0 monetary (e.g., represented by United States dollars or other currency) or have some other 
form, such as credits, affinity points, frequent flier miles, vouchers, barter points, etc. 

DESCRIPTION OF THE FIGURES 

FIG. 1 is a block diagram depicting a system for conducting value exchange 
1 5 transactions in accordance with an embodiment of the present invention. 

FIG. 2 is a flowchart illustrating one method of conducting a value exchange 
transaction in accordance with an embodiment of the invention. 

FIG. 3 depicts one form of an indirect value exchange transaction from a first user 
to a second user performed on the first user's mobile client device in accordance with an 
20 embodiment of the invention. 

FIG. 4 depicts one form of a direct value exchange from a first user to a second user 
conducted with the user's mobile client devices in accordance with an embodiment of the 
invention. 

25 DETAILED DESCRIPTION 

The following description is presented to enable any person skilled in the art to 
make and use the invention, and is provided in the context of particular applications of the 
invention and their requirements. Various modifications to the disclosed embodiments will 
be readily apparent to those skilled in the art and the general principles defined herein may 
30 be applied to other embodiments and applications without departing from the spirit and 
scope of the present invention. Thus, the present invention is not intended to be limited to 
the embodiments shown, but is to be accorded the widest scope consistent with the 
principles and features disclosed herein. 

3 
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The program environment in which a present embodiment of the invention is 
executed illustratively incorporates a general-purpose computer or a special purpose device 
such as a hand-held computer. Details of such devices (e.g., processor, memory, data 
storage, display, wired/wireless communication capability) are omitted for the sake of 
5 clarity. 

It should also be understood that the techniques of the present invention might be 
implemented using a variety of technologies. For example, the methods described herein 
may be implemented in software executing on a computer system, or implemented in 
hardware utilizing either a combination of microprocessors or other specially designed 

10 application specific integrated circuits, programmable logic devices, or various 

combinations thereof. In particular, the methods described herein may be implemented by 
a series of computer-executable instructions residing on a storage medium such as a carrier 
wave, disk drive, or computer-readable medium. Exemplary forms of carrier waves may 
take the form of electrical, electromagnetic or optical signals conveying digital data streams 

1 5 along a local network or a publicly accessible network such as the Internet. 

introduction 

In one embodiment of the invention a system and method are provided for 
facilitating an exchange of value between two or more persons using client computing 

20 devices. Values that are exchanged may be monetary in nature (using any currency) or may 
take other forms, such as credits, debits, discounts, vouchers, certificates, mileage (e.g., 
frequent flier miles), etc. The computing devices used to conduct an exchange transaction 
may or may not be portable in nature, and may employ virtually any communication media, 
including both wired and wireless. In one implementation of this embodiment, at least one 

25 user employs a portable computing device such as a handheld or palmtop computer, a smart 
telephone, a two-way pager, etc. A computing device suitable for this embodiment may 
always be linked to or in communication with another device (e.g., a system server), such 
as a networked personal computer, or may be disconnectable, such as a hand-held persona] 
digital assistant (PDA). Thus, a value exchange transaction may be conducted offline or 

30 online, while connected or disconnected from other system components. 

A system according to this embodiment of the invention includes at least one highly 
accessible computer server configured to facilitate value exchanges. Illustratively, a user 
who wishes to initiate a value exchange or value transfer with another party is registered 
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with the server beforehand (e.g., an account is established for the user on the server). The 
other party may or may not be a registered user at the time the transaction is initiated or 
communicated to the system. 

In one method of conducting a value exchange according to this embodiment of the 
5 invention an entity involved in the exchange may be known by an identifier that has 
meaning or use outside of the system, such as an electronic mail address, a telephone 
number, a social security number, etc. Illustratively, each such identifier is only associated 
with one person or entity, thus promoting accountability. In an alternative method, 
however, multiple users or accounts may be associated with an identifier. 
] 0 In one implementation of a method of conducting a value exchange a registered user 

of the system initiates an exchange with an unregistered party by identifying that party to 
the system server by his or her electronic mail address. The registered user may provide 
various details of the value exchange, such as the form of the value (e.g., a monetary 
amount, a number of credits or affinity points), a date on which to effect the transfer, the 
1 5 unregistered party's name, etc. The system may then attempt to contact the unregistered 
party (e.g., via the provided electronic mail address), notify him or her of the value 
exchange, identify the initiating user and invite the unregistered party to connect to the 
server and close the exchange. The unregistered party may be required to register with the 
system in order to close the transaction. For example, if the value exchange is to the 
20 benefit of the unregistered user, he or she may wish to leave the value in the system in order 
to use it to conduct an exchange with yet another party. Alternatively, the unregistered 
party may be permitted to provide just enough information (e.g., credit card number, 
address) to allow the system to close the transaction, without being registered. 

In different embodiments of the invention the value exchange may be initiated by 
25 the person who owes or is owed the value to be exchanged. Further, the value that is 

exchanged may be of virtually any form and/or may be transformed in nature. For example, 
a monetary amount or a credit or voucher held by a first user and accepted by a second user 
may be transferred from the first user to the second user in exchange for goods or services. 
Or, the value may change from one currency to another or from being monetary in nature to 
30 being represented by credits with a merchant, frequent flier miles, or some other value. 
Thus, a user may pay for goods or services with value in many different forms, including 
currency or points that are used only within the system (e.g., for transactions between 
users). 

5 
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The system may also be configured to allow users to perform normal banking 
operations (e.g., withdrawals, deposits, transfers), stock transactions, electronic ticketing, 
eta In another embodiment of the invention a third party may be involved to hold the value 
in escrow until a transaction is closed. 

5 Value may be introduced into the system (and credited to a user's account) via cash, 

check, debit, or virtually any other method that is presently used or that becomes accepted 
in the business community. Value may exit the system in these and similar forms. 

In alternative embodiments of the invention a distributed system described herein 
may be used for forms of communication other than value exchanges. For example, in one 

10 alternative embodiment the system may be used to spread or disperse software among 
multiple users. Illustratively, a registered system user could then provide an unregistered 
person with the system software and thereby allow them to conduct a transaction. 
Advantageously, the software could be transmitted between users' client devices using 
wired or wireless communications. 

15 

One Embodiment of a System for Facilitating a Value Transfer 

FIG. 1 depicts an illustrative system for facilitating value transfers according to one 
embodiment of the invention. Alternative embodiments of the invention may incorporate 
any subset of the components of the illustrated system. 

20 The system of FIG. 1 includes central database 102, which is configured to store 

various information used to facilitate value exchange transactions. Illustratively, the 
information stored in database 1 02 includes accounts for registered users of the system as 
well as various information pertaining to unregistered users participating in or invited to 
participate in a transaction. User information for registered and/or unregistered users may 

25 include user identifiers (e.g., name, electronic mail address, telephone number, network 
address, physical address), transaction records, account balances in one or more different 
forms (e.g., money, frequent flier miles, store credits, affinity points, vouchers, coupons, 
discounts), preferred communication methods (e.g., electronic mail, wireless voice), 
security data, etc. 

30 In the system of FIG. 1 , database 1 02 is accessed by communication server 1 04, 

synchronization server 106, financial server 108 and possibly security server 1 10. In this 
embodiment, communication server 104 and/or other system servers are configured to 
interact with one or more users through communication network 120. For example, 

6 
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communication server 1 04 may be or may include a web server, telephone switch, DSLAM 
(Digital Subscriber Line Access Multiplexer), etc. 

A network presence, such as a web site on the Internet, that is hosted by 
communication server 1 04 may serve as a primary access point to the system for new and, 
5 possibly, existing users. Illustratively, users are given account names and passwords with 
which to access the system after being registered. Other forms of security (e.g., digital 
certificates, biometric devices) may be employed in other embodiments of the invention. 

In one embodiment of the invention a user may download software for his or her 
computing device from communication server 104. In particular, communication server 
10 1 04 may allow a person to register with the system, access and/or modify account 

information, conduct and clear transactions, etc. A user may be required, however, to 
register with the system before being able to initiate or close a transaction. 

Synchronization server 106 in the illustrated embodiment is configured to 
synchronize information stored on the system with users' client computing devices and 
1 5 locally stored data. Illustratively, a user may connect to the synchronization server to 

upload and/or download details of transactions (e.g., value exchanges) that involve the user. 
During a synchronization session, a user's client may receive updated account information 
(e.g., reflecting cleared transactions), may authorize the system to charge additional funds 
to the user (e.g., by charging a credit card or transferring funds from a bank account), 
20 access customer service, query the status of a transaction, initiate a new transaction, etc. 
Financial server 108 is configured to interface with one or more financial 
institutions, which may, in one embodiment of the invention, be external to the system. 
Thus, the financial server may interact with credit card companies, banks (including 
traditional and online banks) and other entities that handle or process value in suitable 
25 forms; in particular, the financial server may be configured to transfer funds through the 
ACH (Automated Clearing House). Financial server 108 may be configured to 
automatically generate a charge or credit to a user's account with an external financial 
institution when the user's system account balance falls below or rises above a 
predetermined threshold. Further, the external value that the system can access for a user 
30 through financial server 1 08 may affect the number of transactions that the user can 
conduct or the amount of value in a transaction. 

Security server 1 1 0 may cooperate with one or more of database 1 02, 
communication server 104, synchronization server 106 and financial server 108 to apply, 

7 
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ensure or enforce security for value exchanges and actions related to value exchanges. In 
one embodiment of the invention digital signatures may play a large part of the security 
scheme. DSA (Digital Signature Algorithm), a variant thereof (e.g., ECDSA or Elliptical 
Curve DSA), RSA or other digital signature protocol may be used. Symmetric 
5 cryptographic schemes such as DES (Digital Encryption Standard) may also be applied in 
the same or different embodiments. Message authentication codes may be used to verify 
the integrity and authenticity of messages exchanged between the system and a user. 

In a present embodiment of the invention public key encryption techniques may be 
used with digital certificates to create ciyptographically verifiable transactions and prevent 
10 their repudiation. Symmetric encryption schemes may be employed for secure storage of 
data (e.g., on users* client devices and/or on the system). 

Illustratively the organization operating the value exchange system may act as a 
Certificate Authority and certify individual users, while certified users may, in turn, certify 
individual transactions. Certified users may be issued identity certificates for use in value 
15 exchange transactions. 

An identity certificate may include information such as the user's name, electronic 
mail address (or other meaningful identifier that identifies the user, such as a telephone 
number or social security number), account number or name, etc. Illustratively, an identity 
certificate also includes a public key of the user, which may be used to verify the 
20 authenticity of transactions conducted by the user. 

Individual users generate transaction certificates for transactions they conduct or 
initiate and the system authenticates them with the users' public keys (e.g., during 
synchronization). A transaction certificate may include the value being exchanged, an 
identifier of another party to the transaction, other details (if necessary or desired), and may 
25 be signed with the user's private key. In one embodiment, a user's client computing device 
generates the public/key pair during user registration, and the private key is retained only 
on the client device. 

The illustrated system may communicate with users through various types of 
communication media. Communication network 120 may thus comprise a traditional wired 
30 network (e.g., the Internet) and/or a wireless network usable by portable devices such as 
portable computers (e.g., palmtop or handheld), smart (e.g., web-enabled) telephones, two- 
way pagers, etc. Therefore, users may interact with the system by operating devices such as 
client computer 122a, portable client computer or digital assistant 122b, wireless telephone 
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122c and/or other devices capable of communicating with communication server 104 
and/or synchronization server 106. Illustratively, portable client computer 122b may be 
configured to conduct value exchanges with, or communicate them to, the system 
independently and autonomously. Or, in an alternative embodiment, portable client 
5 computer 122b may be operated to record details of an exchange in a disconnected mode 
and then, when connected (e.g., docked) with another computing device (e.g., computer 
122a) to forward those details to the system in order to finalize the exchange, and/or 
synchronize with the system. 

A portable client device employed by a user to participate in a value exchange 
10 transaction may incorporate a series of instructions for interacting with the system. For 
example, in one embodiment of the invention a user's client device includes a wallet 
application that allows the user to access his or her account balance(s) while connected to 
the system and/or while disconnected from the system. Illustratively, in this embodiment 
of the invention a user's device periodically connects to synchronization server 106. 
1 5 During such a connection the user's device communicates with the server to send and 
receive new transaction information (e.g., details of new value exchanges involving the 
user) and/or receive updated account information (e.g., to reflect closed transactions). The 
user may also authorize or perform other activities involving his or her account, such as 
transfer value to or from a system or institution external to the value exchange system. 

20 

One Method of Conducting a Value Exchange 

In one embodiment of the invention a value exchange transaction may be conducted 
by a single user (e.g., with his client device), while connected to or disconnected from a 
system server (e.g., communication server 104, synchronization server 106 of FIG. 1) or 

25 another party's client. In particular, in one embodiment of the invention a user initiates a 
transaction by submitting it to the system, which then takes action to close the transaction 
by notifying another participant, and possibly registering the other participant with the 
system. In an alternative embodiment, however, a transaction may be conducted in a direct 
communication between two (or more) parties, after which details of the transaction are 

30 submitted to one of the system servers. In this alternative embodiment, at least one of the 
parties (e.g., from whom value is being transferred) may be required to be registered with 
the system. 
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Illustratively, a transaction cannot be closed or finalized until the system learns of 
the transaction from one of the involved parties, identifies the other participant(s) and 
determines how to transfer the value. Closure of a transaction may include the actual 
transfer of value from one party (e.g., in a first account and/or form) to a second party (e.g., 
5 to another account and/or form). Parties to a transaction may need to be registered with the 
system and/or provide certain information (e.g., to identify a party, verily a party's identity, 
determining how to transfer value to or from the party) before the transaction can be closed. 

In this section, one or more methods are described for using a value exchange 
system such as that depicted in FIG. 1 to effect a value exchange between two or more 
10 parties. The methods and operations described here may be altered or modified for 

different types of computing devices that a party may employ and/or different system or 
transaction configurations without exceeding the scope of the invention. 

In one embodiment of the invention the system of FIG. 1 may be envisioned as a 
system for facilitating or conducting a financial transaction involving two or more persons. 
1 5 Dlustratively, at least one person in the transaction is already registered (e.g., has an 

account) with the system so that at least one form or conduit for transferring value exists. 
Advantageously, however, a registered user may initiate a transaction with an unregistered 
party, who may be identified to the system with an existing identifier such as an electronic 
mail address, telephone number, IP (Internet Protocol) address, etc. Thus, in this 
20 embodiment identifiers associated with unregistered users (and/or registered users) may 
already have significance or use outside of the system and there may thus be some degree 
of assurance that they can be reached through or with those identifiers. 

Once known to (e.g., registered with) the system, however, a user may conduct 
value exchanges and other transactions using portable, semi-portable and other computing 
25 devices. In particular, the system enables a user to conduct a secure transaction from his or 
her client device directly (e.g., to another user or person having a compatibly equipped 
device) or indirectly (e.g., by describing or submitting the transaction to a system server, 
which may then notify another transaction party). 

Illustratively, in a direct transfer the parties may exchange cryptographic tokens in 
30 order to prevent later repudiation and authenticate the transaction to the system, and, once 
the system is informed of the transaction by at least one party, the transaction can be closed. 
In an indirect transfer the system may contact another party (e.g., by electronic mail or 
telephone) on behalf of an initiating user and, if the party is not already registered, invite 

10 
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that party to register with the system in order to receive and/or conduct their own transfers 
or exchanges. In one embodiment of the invention the invited party may, of course, be able 
to satisfy his or her part of the transaction (e.g., receive or pay money or other value) 
without registering with the system. For example, he may send payment to or receive 
5 payment from the system in a traditional form (e.g., check, credit card, debit card). 

With reference now to FIG. 2, an illustrative method of conducting an indirect value 
exchange transaction according to one embodiment of the invention is presented. The 
illustrated method is suitable for use with the system depicted in FIG. 1 . 

In state 200, a first user (USER1) registers with the system, one method of which is 
10 described in a following section. Illustratively, as part of the registration process USER1 
provides his or her name and residence/postal address, a meaningful identifier (e.g., 
electronic mail address, telephone number, social security number) and pertinent financial 
information. Financial data provided by USER1 may include a credit card or bank account 
to be credited or charged for individual transactions and/or when the value of a transaction 
1 5 exceeds a predetermined limit. In particular, users may be assigned limits on how much 
value they can transfer through the system, based on the financial data regarding them, the 
degree to which their personal information (e.g., address) can be verified, etc. The limit 
may affect the size or number of uncleared transactions that a user may be involved in at a 
given time. 

20 A registered user may be assigned an account number or other identifier within the 

system. As mentioned above, however, a party may be included in a transaction by 
specifying an externally meaningful identifier (e.g., electronic mail address, telephone 
number) associated with the party. USER1 may register with the system, and conduct 
transactions, using virtually any form of client device (e.g., handheld or palmtop computer, 

25 desktop, web-enable telephone) having the ability to communicate with another computing 
device (e.g., a system server). 

In the presently described embodiment of the invention a digital certificate is 
generated for or provided by USER1 as part of the registration process. Illustratively, a 
certificate generated for USER1 includes USERFs name and electronic mail address (or 

30 other meaningful identifier) and a public key signed by the system, all of which are 

encrypted by a code (e.g., a Personal Identification Number or PIN) previously assigned to 
or chosen by USER1 . In one method of registering a user described in a later section, a 
public/private pair of cryptographic keys is generated (e.g., by the user's client or security 
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server 110) and the private key is retained only by the client or other computer system 
operated by the user. 

In state 202 USER1 enters a transaction in his client using software provided by the 
system. Illustratively, USER1 simply enters the electronic mail address, telephone number 

5 or other identifier of a party (e.g., USER2) with whom he wishes to exchange value, plus 
the value to be transferred. In this embodiment, the value may flow in either direction (i.e., 
from or to USER1). The amount of value that USER1 may transfer (if the value is to flow 
to USER2) may be limited to his system account balance (e.g., which may be stored on his 
client and updated when the client synchronizes with the system). This amount may be 

10 decreased by any other transfers (to other users) that have been requested or initiated but 
not yet cleared. If however, USER1 has provided other payment arrangements (e.g., 
through a credit card, electronic funds transfer), then he may be able to exceed his account 
balance. 

USER1 may be required to enter a security code (e.g., Personal Identification 
1 5 Number or password) to activate the client system software before entering a transaction. 
Illustratively, if an incorrect code is entered a predetermined number of times (e.g., ten), the 
ability to enter transactions may be disabled and USER1 may be required to contact or 
synchronize with the system (as described below) in order to re-enable the client software. 
The software may maintain a list of all parties with whom USER1 has previously 
20 conducted a value exchange transaction, in which case he may just select USER2's 

identifier if she is included in the list. The client system software employed by USER1 
may offer multiple transaction options. For example, USER 1 may be able to initiate a 
unilateral transfer to (or from) USER2. USER1 may also be able to initiate a bilateral 
transaction if his client and USER2*s client are capable of direct (e.g., wireless) 
25 communication. Yet further, USER1 may be able to transmit the client system software to 
USER2*s client device. In this case, however, USER2 may not be able to transfer value to 
another party until she registers with the system (and opens an account). 

At some time after entering the transaction in his client, in state 204 USER1 
synchronizes with synchronization server 106. In particular, USER1 initiates whatever 
30 commands or actions are necessary to connect his client with the synchronization server. 
The client may be able to connect directly, perhaps through a wireless connection, or 
through any number of intermediate devices or media (e.g., the Internet). In particular, if 
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USERl's client is a portable device, he may be required to dock it or otherwise connect it 
to another computer system in order to initiate a connection to synchronization server 106. 

Synchronization may be required on a regular basis (e.g., at least once every thirty 
days). If this requirement is not satisfied, the client software may automatically prevent 
5 USER1 from making payments or initiating transactions. In addition, transactions made on 
USER1 *s client may be automatically canceled or nullified if he does not synchronize 
within a certain period of time (e.g., thirty days) after entering the transaction in the client. 

In a typical synchronization process according to one embodiment of the invention, 
USER1 's client connects to synchronization server 106 and identifies USER1 by his system 
1 0 account number (and/or electronic mail address, telephone number or other meaningful 

identifier). The server locates a user record for USER1 (e.g., in database 102) and retrieves 
a code (e.g., a PIN) assigned to or associated with the user. A digital certificate associated 
with USER1, and which is to be transmitted to USER1 during synchronization, is then 
encrypted with this code; this digital certificate may be the certificate that was generated 
1 5 when USER1 was registered. Illustratively, however, the digital certificate may be 

augmented with one or more transaction certificates for transactions involving USER1 that 
have been reported to the system by other users. The digital certificate may also be used to 
pass a new code (e.g., PIN) to USER1 . 

If there is no digital certificate stored on the system for USER1 , the synchronization 
20 server requests USER1 's password and electronic mail address (or other identifier). If this 
information is verified, a new key pair may be generated and a new digital certificate 
issued. 

After the initial synchronization connection is established, the client sends the 
present transaction (and any others it has stored and not already sent) to the server. The 
25 transactions may be sent using digital transaction certificates, as described above. The 

client is informed if any previous transactions of USER1 have cleared (e.g., another party in 
a previous transaction may have connected to the system and accepted the transaction), in 
which case they may be removed from the client The server may then prioritize uncleared 
transactions according to some criteria (e.g., date, time, other party(ies), transaction value, 
30 direction of value transfer). 

A user's client (and/or a system server) may maintain a transaction log in which to 
record transactions conducted by and/or involving the user. An entry is then made in the 
log when the user initiates a transaction. An entry may also be made in the log for each 
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transaction (e.g., initiated by another party) that the client learns of from a system server 
(e.g., during synchronization). Entries may be removed or archived after their associated 
transactions clear. 

In one method of the invention account balances are altered during the 
5 synchronization process. In particular, USER1 T s account is debited for all values being 
transferred away from USER1 . Conversely, however, USER1 's account may not be 
credited for incoming value transfers initiated by USER1 until the other parties to such 
transfers synchronize or otherwise acknowledge or approve them (e.g., until the 
transactions clear). If USER1 *s system account has an insufficient balance to make a 
10 transfer (e.g., to USER2), his credit card or other value stream may be tapped (e.g., by 
financial server 1 08) to cover them. 

Thus, in state 204, once USER1 has connected to the synchronization server the 
transaction is communicated to the system along with any other transactions not yet 
submitted. In exchange, the synchronization server may inform the client of any closed 
1 5 transactions and download transactions that involve USER1 that were initiated by other 
parties. Therefore, the synchronization process of state 204 may involve updating 
USERl's client and the system with various transactions to which USER 1 is a party. 
Account balances on a system server and/or the client may be altered accordingly during 
the synchronization process or afterwards. 
20 In state 206 a system server (e.g., synchronization server 106) receives the details of 

the USER1/USER2 transaction (e.g., including an identifier of USER2 and the value to be 
transferred). If the value exchange is from USER1 to USER2, USER1 *s account may be 
automatically debited by the amount of the transfer, this may require a charge to a credit 
card or bank account associated with USER1 . In the illustrated embodiment, however, 
25 account updates may be postponed until a later stage of the procedure. 

In state 208 the system attempts to inform USER2 of the transaction. In this 
embodiment the system uses the identifier submitted by USER1 (e.g., by generating an 
automated electronic mail message or voice message). If, however, USER2 is a registered 
system user, her account may be examined to determine if she has a different, preferred, 
30 method of receiving transaction communications. If USER2 is not a registered user, the 
automated message includes details concerning what she should do to receive the value. 
For example, a system web site hosted by communication server 1 04 may be identified and 
USER2 invited to connect to the site and register. 
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In state 210, which may occur simultaneously with state 208, the system determines 
whether USER2 is a registered user. If so, then she need not register and the procedure 
continues at state 214. 

In state 212, however, USER2 is unregistered at the time of the transaction with 
5 USER1 and therefore may be required to register before the transaction can be closed, 
particularly if the value is to be transferred from USER2 to USER1 . By registering with 
the system, USER2 may receive or submit the transaction value using virtually any normal 
means for conveying value (e.g., credit card, check, debit card, electronic funds transfer). 
However, in one alternative embodiment of the invention USER2 may not be required to 
10 register. In particular, in this alternative embodiment she may be able to make a one-time 
payment to or withdrawal from the system (e.g., with a credit card or check). 

In state 214 USER2 accepts or acknowledges the transaction. Acceptance may be 
implied if she was an unregistered party and registers in response to the invitation from the 
system. State 214 may only be required for transactions in which the value is to be 
15 transferred from USER2 to USER1 . In other words, when a first user initiates a transaction 
to transfer value to another user, the other user's acknowledgement may not be needed. 
However, if a first user initiates a transaction to receive value from another user, it may be 
necessary to receive approval from the other user before closing the transaction. 

In state 216 the transaction is closed by altering system account balances for USER1 
20 and USER2 according to the value of the transaction. In addition, the user that is providing 
value to the other party may need to inject additional value into the system in order to cover 
the transaction. Thus, financial server 108 may charge the user's credit card, conduct an 
electronic funds transfer or take other action. Further, if there is a limit or maximum on the 
receiving user's account balance, the financial server may credit value to his or her credit 
25 card, debit card, bank account, etc. 

In state 21 8 the client devices for USER1 and USER2 are updated according to the 
transaction (and, possibly, other transactions). If, however, USER1 or USER2 are 
disconnected from the system at the time, their devices may be updated (e.g., by 
synchronization server 1 06) the next time they connect. After state 21 8 the illustrated 
30 procedure ends. 

In a present embodiment of the invention USER1 may be granted affinity points or 
some other reward for introducing a new user to the system. In particular, if USER2 was 
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not a registered user at the time USER1 submitted the transaction to the system, he may be 
rewarded if USER2 registers in response to the transaction notification from the system. 

The embodiment of the invention illustrated in FIG. 2 and described above is but 
one method of conducting a value exchange with a system such as that depicted in FIG. 1 . 
5 This method may be readily modified to accommodate the use of various types of client 
devices, communication media and communication sequences. In particular, the preceding 
method may be applied as described, or slightly altered, to conduct a value exchange 
between a registered user and an unregistered party, between two or more registered users, 
or in virtually any circumstance in which value is being exchanged. 
] 0 FIG- 3 depicts one form of an indirect value exchange performed by one user on a 

mobile client device. In FIG. 3 UserA enters the value exchange in her device, ClientA. 
The transaction is then submitted to a system server, possibly during a synchronization 
process. The amount of the value (if UserA is authorized to transfer the full value) is 
removed from UserA's account and UserA's client device is updated with her new account 
1 5 balance. Additional funds or value may be retrieved from a bank, credit card, ACH, or 

other financial source associated with UserA if her account balance falls below a minimum 
level or the transfer is necessary in order to complete the requested exchange. The value is 
deposited in UserB's account, which may require an account to be created for UserB if he is 
not already a registered user. 
20 In one embodiment of the invention the value of a transaction may be held in 

escrow. In this embodiment the user initiating the transaction chooses an option to have the 
value placed in escrow. If this user is the payor (e.g., the party from whom value is being 
transferred), the user's account may be debited as soon as the transaction is communicated 
to the system, but instead of being credited to the specified recipient, it is held in an escrow 
25 account Illustratively, the value recipient is notified that a value is being held and, 

possibly, the conditions for releasing it. The system may require that both parties agree 
before the funds are transferred to the recipient or back to the payor. The system may be 
configured, by default, to complete the transfer after a certain period of time if there is no 
objection from a party or, conversely, to cancel the transaction unless one or both parties 
30 affirm it within the specified period of time. 

The following sub-sections describe methods of conducting a value exchange in 
different environments or circumstances from those described above. 
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CONDUCTING AN ONLINE VALUE EXCHANGE 

In one alternative method of conducting a value exchange, a user connects to the 
value exchange system (e.g., the system of FIG. 1) through an Internet connection (e.g., 
from a desktop or wireless client). In this method, communication server 104 of the system 
5 of FIG. 1 comprises a web server hosting a web site for the system. A user wishing to 
initiate a transaction connects to communication server 104 and satisfies the necessary 
security requirements by providing a username, account name or other identifier (e.g., 
electronic mail address, telephone number) and a password. In one alternative of this 
embodiment, a cryptographic security policy may be enforced that requires the user to 
10 provide cryptographic authentication or a security token. 

The user completes an online form by providing information such as an identifier 
(e.g., electronic mail address, telephone number, social security number, account name) of 
another party to the transaction and the value to be transferred. Also, the user may specify 
whether the value is to be transferred from him to the other party or vice versa. The user's 
15 interface with the system (e.g., the web page presented to the user when he connects or logs 
in) may be personalized to the user. In particular, identifiers of parties with which the user 
has transacted in the past may be available for ready selection, in which case the user need 
not remember or enter an identifier but can, instead, pick one from a list 

If the other party is already a registered system user, the system may then proceed to 
20 conduct the value transfer. Illustratively, if the value is to flow from the initiating user to 
the other party, the system may not require the approval or authorization of the other party 
to finalize or close the transaction. The system may simply send notification of the 
transaction (e.g., via electronic mail) to the party. In contrast, if the value is to flow from 
the other party to the initiating user, the system may require the other party's approval 
25 before closure. When the value of the transaction flows from the initiating user to the other 
party, the user's account may be debited by the amount to be transferred even before the 
transaction closes (e.g., before the other party accepts the transaction). 

If the other party is not a registered system user, the system notifies the party of the 
pending transaction by using the identifier provided by the initiating user. The notification 
30 may thus be sent via electronic mail. Illustratively, the notification identifies the user who 
initiated the transaction, informs the other party of the amount of the transaction and 
specifies how/where (e.g., a web page or site) to complete the transaction. In order to 
receive the value or submit the value requested by the initiating user, the other party may 
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then connect to the system and register. A method of registering a new user is described in 
a following section. 

Unlike an offline transaction (e.g., using a disconnectable portable computing 
device), when conducting a transaction online a user may be able to access account 
5 information and/or close the transaction in real time. 

The method of the invention described in this sub-section is suitable for application 
with clients that can establish and maintain a real-time link with the system, whether 
through the Internet via a wired or wireless connection, through a telephone connection 
(wired or wireless), etc. 

10 

CONDUCTING A DIRECT (CLIENT TO CLIENT) VALUE EXCHANGE 

In one alternative embodiment of the invention a method is provided in which two 
parties employ their client computing devices to conduct a value exchange. If they are 
disconnected from the system while conducting the transaction, after the transaction one or 
1 5 both of them submit the transaction to the system (e.g., via communication server 1 04 or 
synchronization server 106 of the system of FIG. 1). This method is particularly suited to 
the use of mobile computing devices and smart or web-enabled telephones that can 
communicate directly (e.g., via a wired or wireless communication medium) with another 
client. 

20 The option to conduct a client-to-client transaction may be just one of several 

options available to a user. For example, the system software installed on the client device 
may also enable one user to transmit the system software to another user, conduct a 
unilateral transaction (e.g., as described above in conjunction with FIG. 2), view his or her 
account balance(s) (which are updated each time the client is synchronized) or transaction 

25 log, use a calculator, etc. 

If the user elects to make a client-to-client transaction, the user's client may 
automatically attempt to establish contact with another client. The client may be 
configured to make such connections in a wireless or wired mode. 

In this method each user activates his or her computing device and one of them 

30 operates the installed system software to initiate a payment to or from the other user. This 
may require the user to enter a Personal Identification Number (PIN) to activate the 
software. The other user's client may then prompt him or her to accept or reject the 
transaction, particularly if the value of the transaction is to be transferred from the other 
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user to the first user. If only one user has the software installed, the software may be 
transmitted to and installed on the other user's device as part of, or as a precursor to, the 
transaction. 

Illustratively, the account balance of the user giving the value (e.g., as indicated in 
5 the system software) decreases when the transaction is conducted. Closing the transaction 
may require the paying user's credit card, debit card or other method of providing value to 
the system to be charged (e.g., if his or her account balance is too low). The transaction 
may not be closed until one of the users forwards the transaction to the system (e.g., during 
a synchronization session with synchronization server 106). The client software may allow 
1 0 a user to make notes or comments to be saved in a transaction log with the details (e.g.* 
value, other user's identifier) of the transaction. 

In one method of conducting a direct value exchange, the users may exchange 
digital certificates (e.g., transaction certificates) or other tokens in order to authenticate 
each other and/or demonstrate to the system that the transaction is valid and was not 
1 5 spoofed or faked by one of the parties. 

FIG. 4 depicts one form of a direct value exchange performed between two users 
having mobile client devices. In FIG. 4 UserA electronically transfers the value from her 
ClientA to UserB's ClientB. The transaction is then submitted to a system server by one of 
the transaction parties, possibly during a synchronization process. The amount of the value 
20 (if UserA is authorized to transfer the full value) is removed from UserA's account and 
deposited in UserB's account. Additional funds or value may be retrieved from a bank, 
credit card, ACH, or other financial source associated with UserA if her account balance 
falls below a minimum level or the transfer is necessary in order to complete the requested 
exchange. Both of the users* client devices are updated with their new account balances. 

25 

Canceling a Value Exchange 

In various situations a user may wish or need to reverse or cancel a value exchange. 
For example, while attempting to conduct a transaction with another party a user may 
provide an incorrect identifier - such as a non-existent or invalid electronic mail address or 
30 a valid electronic mail address that is associated with someone other than the desired party. 
In one embodiment of the invention a value transfer may be undone if the situation 
warrants. In particular, if it is determined that an exchange should be undone, the system 
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may cancel the value transfer, reverse it, redirect it (e.g., transfer the value to a third party) 
or nullify it in some other manner. 

If an identifier of a transaction party (e.g., electronic mail address) provided by a 
user is unusable (e.g., invalid), the user may specify whether to reverse or redirect the 
5 transfer or the system may apply a default action (e.g., return the value to the user). This 
situation may occur, for example, if an electronic mail notification of the transaction to the 
other party is undeliverable (e.g., incorrect address, party's electronic mail server is 
unavailable). 

If the party identifier is a valid identifier, but is not associated with the intended 
10 party, rectifying the situation may be more difficult. For example, if the transaction has 
already been closed and the value credited to the incorrect party, the transaction may be 
irreversible. The initiating user may, of course, contact that party and attempt to retrieve 
the value. 

If the party identifier is valid but is not associated with the intended party and the 
1 5 transaction has not yet closed, the user may be able to retrieve the value. Some period of 
time (e.g., six months) may be established for automatically canceling or reversing 
uncleared transactions or during which the user may request cancellation of the transaction. 
For example, if a user initiates a transaction and six months later the recipient still has not 
claimed the value, the system may automatically reverse or cancel the transfer. Before that 
20 time, however, the initiating user may have to request the transaction be nullified. The 
system may attempt to contact the incorrect party before doing so. 

Registering a New User in One Embodiment of the Invention 

As described earlier, in one embodiment of the invention a user must be registered 
25 with the value exchange system before being able to initiate or close a transaction with the 
system. This section describes one method of registering a new user, during which the user 
may download or otherwise receive software configured to allow the user's client device to 
interact with the system and/or other user's clients. 

Illustratively, a new user may register with the system in many ways, such as 
30 through a system web site, via a web-enabled telephone, via normal voice telephone 

contact, via electronic or normal mail, etc. The level of access or degree to which a user 
may employ the system after registration may, however, depend upon how the user 
registers, how much information is provided during registration, how much of the 
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information is verified, etc. For example, if a user-provided telephone number, electronic 
mail address, street address, and/or other information is all verified, the user may be 
granted greater system access or be allowed to conduct transactions involving more value 
than if the information is incorrect, unverifiable or not provided. 
5 In one embodiment of the invention a potential new user connects to 

communication (e.g., web) server 104 of the system of FIG. 1 and completes a registration 
form. Advantageously, the registration process is done in a secure mode (e.g., with SSL 
(Secure Sockets Layer)). The registration form may elicit or require personal information 
such as name, residential (e.g., street) address, telephone number(s) (e.g., daytime, 
10 nighttime, mobile), etc. Information to be associated with the user's account is also 

requested, such as an electronic mail address, social security number, some information that 
may be used for security purposes (e.g., mother's maiden name), etc. The user may also be 
prompted to enter a password to be used for the new account and/or a PIN (Personal 
Identification Number) for activating system software on the user's mobile device. 
] 5 Illustratively, when the user wishes to initiate or accept a transaction while using his mobile 
device, he may be required to enter the PIN before the software will function. 

The user may be required to agree to specific terms for using the system. The 
system may then attempt to verify one or more pieces of information provided by the user. 
Thus, a confirmation communication may be sent to the user's street address, electronic 
20 mail address, mobile device, etc. A confirmation communication may include a code (e.g., 
a PIN) that the user is instructed to provide to the system (e.g., web server 104) in order to 
complete or continue the registration process. 

In an embodiment of the invention in which a new user registers with the system 
using a smart or web-enabled telephone, the registration process may be tailored to the 
25 device and the limited display means of such a device. Thus, some of the registration 
information (e.g., telephone number, name) could be derived from the telephone or the 
signal received from the telephone. And, the information required of the user may be 
reduced to a minimum if it must be entered through the telephone's keypad. 

Illustratively, some of the information associated with a system user may be 
30 required to be unique. For example, in an embodiment of the invention in which 

transaction participants may be identified by their electronic mail addresses, the system 
may require a one-to-one mapping between addresses and users. In another embodiment 
users may be identifiable by telephone numbers. Again, the system may allow each 
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telephone number to be associated with only a single user, although extension numbers 
could, perhaps, be added to differentiate between multiple users reachable at one number. 
One reason for this limitation is to allow a value exchange participant to identify another 
participant using a common identifier that is, or may be, already known. In one alternative 
5 embodiment, however, a user may be known by an account number or other identifier 
generated by or for the system. In another alternative embodiment, some or all users may 
be identified by multiple identifiers, in which case multiple users may be associated with a 
particular identifier (e.g., electronic mail address) but also have other identifiers that 
distinguish them. 

10 After a user is registered with the system, he or she may then establish an initial 

and/or default method of providing funds. For example, the user may identify a credit card, 
a bank account, a debit card or other source of value to be charged when the user transfers 
value to another person or at other times when value must be added to the user's system 
account The amount of system credit or the limit placed on the user's system activity may 

15 be determined in part or in whole by the form of value transfer the user employs, the level 
of credit or value transfer authorized by the user's financial institution, the degree to which 
the user's personal or account information has been verified, etc. For example, if the user's 
street address cannot be verified (e.g., he or she does not submit the code mailed to the 
address they provided), or the address of his/her credit card does not match his/her mailing 

20 address, or the user's credit card limit is low, then he or she may be limited to a first level 
of system usage. If however, the user's personal or financial information is verified and/or 
their credit card limit is relatively high, he or she may be allowed to transfer much more 
value through the system. In short, the level of trust, authentication, verification or security 
that the user provides to the system may affect the amount or level of system usage the user 

25 is granted. 

Until a user submits credit or debit information his or her system limit may be kept 
at zero, indicating that he or she is not authorized to transfer value to other parties* The 
user may, however, be able to receive value transfers as soon as he or she is registered. 

A user may also be able to place value in his or her system account through direct 
30 deposit, a personal check, electronic funds transfer, etc. Illustratively, however, funds 
submitted via these methods are not available for transfer until they clear. Users may 
choose multiple methods of depositing value into their accounts (and retrieving value from 
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their accounts) and may be required to provide whatever information is necessary (e.g., 
bank routing or account number) to implement those methods. 

Registration may or may not be required before a user can download and install 
software configured to allow a user to make a value exchange. A software download may 
5 be part of the registration process or may, alternatively, be conducted before or after a user 
registers. The following is a description of a software download/installation process 
according to one embodiment of the invention. 

To receive the software the user first connects his client device to an appropriate 
system server (e.g., communication server 1 04 or synchronization server 106 of the system 
10 of FIG. 1). The user makes a choice to download the software and may need to identify his 
or her device so that the correct software is provided. A registered user may also identify 
himself to the system, in which case the system may automatically determine (e.g., by 
communicating with the user's device or referring to account information in database 102) 
whether the user needs to update his software. 
1 5 The software that is downloaded may depend upon the user's normal or expected 

method of accessing the system. For example, if the user employs a portable device the 
downloaded software may be tailored to the particular device to allow it to communicate 
and interact directly with the system. If the portable device is a disconnectable device that 
must be docked with or otherwise connected to another computer system (e.g., a desktop or 
20 workstation, herein termed a "conduit" computer) in order to communicate with the system, 
then the downloaded software may include modules for the disconnectable device and/or 
the other computer system. 

The appropriate software is then copied to the user's device. Other software, 
perhaps provided by a manufacturer or vendor of the user's device may need to be in 
25 operation in order to fully install the system software. For a disconnectable portable 

computing device, a first software module is installed on the conduit computer, after which 
the device may be docked in order to install a second module on the device. The first 
module may be configured to synchronize the user's locally stored data and information 
with synchronization server 106, while the second module may be configured to conduct 
30 disconnected transactions and communicate them to the conduit computer. Thus, after a 
transaction is conducted with the client while disconnected, it is communicated to the 
conduit computer, which then synchronizes with synchronization server 106. The client 
software module may be considered a '"wallet" application. 
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Illustratively, after new software is downloaded, and before the user can use his 
portable device to transfer value to another person, he must be authenticated to the system. 
Thus, in one embodiment of the system the user inputs his usemame (e.g., account name, 
electronic mail address or other system identifier) and password, which the conduit passes 

5 to the system (e.g., synchronization server 106, security server 1 10) for verification. If the 
user is verified, a pair of cryptographic keys may be generated (e.g., by the conduit 
computer or security server 1 10). In the presently described embodiment the user's conduit 
computer generates the key pair and passes the public key to the system to be signed. The 
signed key may be returned in encrypted form (e.g., encrypted with the user's PIN). 

10 Illustratively, both the private key and signed public key are then stored only on the user's 
portable device (i.e., not on the conduit). 

When a user installs new software (e.g., a new version), uncleared transactions may 
be automatically cleared (with synchronization server 106) or archived. If the user installs 
new software on a different device, the digital certificate on the original device may be 

15 invalidated. 

The foregoing descriptions of embodiments of the invention have been presented 
for purposes of illustration and description only. They are not intended to be exhaustive or 
to limit the invention to the forms disclosed. Accordingly, the above disclosure is not 
20 intended to limit the invention; the scope of the invention is defined by the appended 
claims. 
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What Is Claimed Is: 

1 . A method of facilitating a value exchange between multiple users in a 
distributed value exchange system, the method comprising: 

5 (a) registering a first user with the value exchange system; 

(b) receiving a value exchange transaction from the first user, wherein said 
transaction involves a second user and includes: 

(i) a pre-existing identifier of the second user, wherein the pre-existing ' 
identifier enables communication with the second user independent of the value 

10 exchange system; and 

(ii) a value to be exchanged between the first user and the second user; 

(c) notifying the second user of said value exchange transaction; and 

(d) allocating said value between the first user and the second user. 

2. The method of claim 1 , further comprising: 

15 (c') registering the second user with the value exchange system if not already 

registered. 

3. The method of claim 1 , wherein said value to be exchanged between the first 
user and the second user is to be transferred from the first user to the second user. 

4. The method of claim 1, wherein said value to be exchanged between the first 
20 user and the second user is to be transferred from the second user to the first user. 

5. The method of claim 3, wherein said value to be exchanged between the first 
user and the second user is receivable by the second user as a redeemable voucher. 

6. The method of claim 5, wherein said redeemable voucher is redeemable by 
the second user by selecting an electronic link provided to the second user. 

25 7. The method of claim 5, wherein the redeemable voucher includes an 

electronic advertisement. 
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8. The method of claim 3, wherein said value to be exchanged between the first 
user and the second user is receivable by the second user through a debit card. 

9. The method of claim 3, wherein said value to be exchanged between the first 
user and the second user is receivable by the second user in the form of a web certificate, 

5 and wherein the method further comprises: 

transferring said value to be exchanged between the first user and the second user 
from the second user to a third user. 

1 0. The method of claim 1 , wherein said pre-existing identifier is a telephone 
number. 

10 11. The method of claim 1 , wherein said pre-existing identifier is an electronic 

mail address. 

1 2. The method of claim 1 , wherein said receiving a value exchange transaction 
comprises: 

initiating a value exchange involving a second user on a mobile client device of said 
15 first user; 

establishing a connection between the first user and the value exchange system; and 
transmitting said value exchange to the system. 



13. The method of claim 1 2, wherein said initiating a value exchange 
transaction comprises establishing a communication link between the first user's mobile 

20 computing device and a second user's mobile client device. 

14. The method of claim 1 , wherein said value exchange transaction is received 
from the first user through a mobile communication device. 

1 5. The method of claim 1 4, wherein the mobile communication device is a 
personal digital assistant. 
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16. 



The method of claim 14, wherein the mobile communication device is a 
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telephone. 

17. The method of claim 14, wherein the mobile communication device is a 
two-way pager. 

1 8. The method of claim 14, wherein said value exchange transaction is 
5 received from the mobile communication device through a wireless network. 

19. The method of claim 14, wherein the mobile communication device is a 
discoimectable device. 

20. The method of claim 1 , further comprising converting said value to be 
exchanged between the first user and the second user from a first form to a second form. 

10 21. The method of claim 20, wherein said first form is a first currency and said 

second form is a second currency. 

22. The method of claim 1 , wherein the form of said value to be exchanged 
between the first user and the second user depends on the pre-existing identifier. 

23. The method of claim 1 , further comprising holding said value to be 

1 5 exchanged between the first user and the second user in escrow with an escrow party until 
said value exchange transaction is completed. 

24. The method of claim 1 , further comprising repeating (b), (c) and (d) for a 
second value exchange transaction between the second user and a third user. 

25. The method of claim 1 , wherein an asymmetric cryptographic scheme is 
20 applied to secure said value exchange transaction. 

26. A method of facilitating an exchange of value between multiple users 
through a distributed transaction system, comprising: 

(a) receiving an instruction from a first user to exchange a value with a second 
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user, wherein the first user is a registered user of the distributed transaction system and the 
instruction includes: 

(i) an identifier of a second user not registered with the distributed 
transaction system, wherein said identifier is usable to identify the second user 

5 independently of the distributed transaction system; and 

(ii) the value to be exchanged between the first user and the second user, 

(b) notifying the second user of said value exchange; 

(c) registering the second user with the distributed transaction system; and 

(d) transferring said value between the first user and the second user. 

10 27. The method of claim 26, wherein said identifier is an electronic mail 

address. 

28. The method of claim 26, wherein said identifier is a telephone number. 

29. The method of claim 26, wherein said instruction is received through a 
mobile communication device operated by the first user. 

15 

30. A method of facilitating a financial transaction between a first user and a 
second user through a distributed financial services system, the method comprising: 

(a) registering a first user with the distributed financial services system; 

(b) receiving a financial exchange request from a mobile communication device 
20 operated by the first user, wherein said financial transaction request includes: 

(i) a pre-existing identifier of a second user participating in said 
financial exchange, wherein said pre-existing identifier is configured to identify the 
second user for a purpose other than conducting a financial exchange with the 
financial services system; and 
25 (ii) an amount of the financial exchange; 

(c) notifying the second user of said financial exchange request; and 

(d) allocating said amount of said financial exchange between the first user and 
the second user. 



31. 



The method of claim 30, wherein said pre-existing identifier is an electronic 
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mail address. 

32. The method of claim 30, wherein said pre-existing identifier is a telephone 
number. 

33. The method of claim 30, further comprising: 

5 (c*) registering the second user with the distributed financial services system 

before allocating said amount of said financial exchange. 

34. A value exchange system for exchanging value between multiple users, 
comprising: 

10 a database configured to store information concerning registered users of the value 

exchange system and details of transactions conducted by the registered users; 

a synchronization server configured to receive a first value exchange transaction 
from a client device operated by a first party, wherein said first value exchange transaction 
involves a second party identified by the first party with an identifier that is capable of 
15 identifying the second party independently of the value exchange system; and 

a communication server configured to receive a connection from the second user 
and register the second party if not already registered. 

35. The system of claim 34, further comprising a financial server configured to 
20 interact with a financial institution to access value to facilitate said first value exchange 

transaction. 

36. The system of claim 34, further comprising a security server configured to 
generate a digital identity certificate that may be used to authenticate the first party. 

37. The system of claim 36, wherein said security server is further configured to 
25 authenticate a digital transaction certificate that may be used to authenticate said value 

exchange transaction. 



38. The system of claim 34, wherein said identifier is one of an electronic mail 
address and a telephone number. 
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